The model-view-controller paradigm is a design pattern often used by applications as a flexible model for object oriented graphics applications. One such application is for graphical applications in an ultrasound system. The paradigm separates the system into three primary elements: (1) model; (2) view; and (3) controller.
The model is an abstract representation of the state of the system. It encapsulates data and functions that operate on it, and serves as a computational approximation or abstraction of a real world process or system. In effect, the model captures the state of a process or system, and how the system works. Typically, there is only one model per system. The model, as an object, has no specific methods associated with it for the interpretation of the information it contains but exists as a high-speed repository of information. One example of a model is a parameter cache, which is a global repository for all of the imaging mode parameters (parameters) in the system. The parameters may be interpreted as representing the state of the system, such as an ultrasound system. In actuality, the parameters are used not only to represent the state of the ultrasound system, but also to represent the state of the application itself. In this manner, the parameters may be viewed as a global database.
The view is a graphic representation of the model, suitable for a user interface or display. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. A view may have a one to one correspondence with a display, knowing how to render to the display. A view attaches to a model and renders its contents to the display. In addition, when the model changes, the view may automatically redraw the affected part of the image to reflect those changes. In an ultrasound system, the view may be represented by visibles and the objects that map them on and off the screen.
The controller is the means by which the user interacts with the application. The controller accepts input from the user and commands the model and/or view to change based on that input. In essence, the controller is responsible for mapping end-user action to application response. For example, if the user modifies an input to the system, such as an input from the keyboard, etc., the controller determines how the application should respond. The controller, thus, directs how to bind the elements of a view to a model, and how to interpret events in the system to change both the model and the view. The controller is typically where the majority of the software code resides in a system based on the model-view-controller paradigm. In the case of an ultrasound system, the controller may be composed of four primary engines: the behavior engine, the user function handler, the data field manager, and the graphics engine.
The behavior engine is responsible for executing the behavior of the User Interface/System Control software subsystem in an ultrasound system. It may comprise a list of behavior objects (BOs). Each behavior object may have a set of zero or more input and output parameters.
Software subsystem control, such as in the ultrasound machine, is very complex and its features are inter-dependent. The complexities may require that some of the behavior engines in the system include circular dependencies. Referring to FIG. 1, there is shown a block diagram of an example of a circular dependency. The example is offered merely for a simple illustration. As shown in the figure, pe8 is an output parameter to BO77 and is an input to BO2. Due to the complexities, prior behavior engines did not include circular dependencies in the behavior objects. Instead, when a behavior engine required a circular dependency, a “leveling process” was used to remove the circular dependency. The leveling process would introduce one or more new behavior object(s) which would account for the circular dependency, thereby simplifying the system. Referring to FIG. 2, there is shown a prior art block diagram in which a leveling process is used. To account for the circular dependency, an additional behavior object, BO2′ is created which may be based on the behavior logic from BO2. However, there are drawbacks to using the leveling process. First, one is required to replace the circular dependency with one or more new behavior object(s) and one or more additional parameters. Second, as more circular dependencies are required, the leveling process becomes exceedingly complicated. Third, the leveling process requires that the sequence of updating the behavior objects is fixed, with a one pass execution for all behavior objects. The sequence is predetermined when initializing the system so that, when there is a change to a parameter in the system, all behavior objects (including the analysis of all input parameters for algorithm updates for the given behavior object), and not just affected behavior objects, are updated. In effect, the updating must begin at the left side of FIG. 2 and end at the right side of FIG. 2. This type of updating is overly rigid and very inefficient.
There is a need, therefore, for an improved method and system for handling circular dependencies in a behavior engine.